home *** CD-ROM | disk | FTP | other *** search
/ Skunkware 5 / Skunkware 5.iso / man / cat.1 / mailcap.1 < prev    next >
Encoding:
Text File  |  1995-07-26  |  11.4 KB  |  265 lines
  1.  
  2.  
  3.  
  4.      MMMMAAAAIIIILLLLCCCCAAAAPPPP((((4444))))       BBBBeeeellllllllccccoooorrrreeee PPPPrrrroooottttoooottttyyyyppppeeee ((((RRRReeeelllleeeeaaaasssseeee 2222))))        MMMMAAAAIIIILLLLCCCCAAAAPPPP((((4444))))
  5.  
  6.  
  7.  
  8.      NNNNAAAAMMMMEEEE
  9.           mailcap - metamail capabilities file
  10.  
  11.      DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
  12.           The _m_a_i_l_c_a_p file is read by the _m_e_t_a_m_a_i_l program to
  13.           determine how to display non-text at the local site.
  14.  
  15.           The syntax of a mailcap file is quite simple, at least
  16.           compared to termcap files.  Any line that starts with "#" is
  17.           a comment.  Blank lines are ignored.  Otherwise, each line
  18.           defines a single mailcap entry for a single content type.
  19.           Long lines may be continued by ending them with a backslash
  20.           character, \.
  21.  
  22.           Each individual mailcap entry consists of a content-type
  23.           specification, a command to execute, and (possibly) a set of
  24.           optional "flag" values.  For example, a very simple mailcap
  25.           entry (which is actually a built-in default behavior for
  26.           metamail) would look like this:
  27.  
  28.           text/plain; cat %s
  29.  
  30.           The optional flags can be used to specify additional
  31.           information about the mail-handling command.  For example:
  32.  
  33.           text/plain; cat %s; copiousoutput
  34.  
  35.           can be used to indicate that the output of the 'cat' command
  36.           may be voluminous, requiring either a scrolling window, a
  37.           pager, or some other appropriate coping mechanism.
  38.  
  39.           The "type" field (text/plain, in the above example) is
  40.           simply any legal content type name, as defined by RFC 822.
  41.           In practice, this is almost any string.  It is the string
  42.           that will be matched against the "Content-type" header (or
  43.           the value passed in with -c) to decide if this is the
  44.           mailcap entry that matches the current message.
  45.           Additionally, the type field may specify a subtype (e.g.
  46.           "text/ISO-8859-1") or a wildcard to match all subtypes (e.g.
  47.           "image/*").
  48.  
  49.           The "command" field is any UNIX command ("cat %s" in the
  50.           above example), and is used to specify the interpreter for
  51.           the given type of message.  It will be passed to the shell
  52.           via the system(3) facility.  Semicolons and backslashes
  53.           within the command must be quoted with backslashes.  If the
  54.           command contains "%s", those two characters will be replaced
  55.           by the name of a file that contains the body of the message.
  56.           If it contains "%t', those two characters will be replaced
  57.           by the content-type field, including the subtype, if any.
  58.           (That is, if the content-type was "image/pbm;
  59.           opt1=something-else", then "%t" would be replaced by
  60.  
  61.  
  62.  
  63.      Page 1                                          (printed 6/30/95)
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.      MMMMAAAAIIIILLLLCCCCAAAAPPPP((((4444))))       BBBBeeeellllllllccccoooorrrreeee PPPPrrrroooottttoooottttyyyyppppeeee ((((RRRReeeelllleeeeaaaasssseeee 2222))))        MMMMAAAAIIIILLLLCCCCAAAAPPPP((((4444))))
  71.  
  72.  
  73.  
  74.           "image/pbm".)   If the command field contains  "%{" followed
  75.           by a parameter name and a closing "}", then all those
  76.           characters will be replaced by the value of the named
  77.           parameter, if any, from the Content-type header.   Thus, in
  78.           the previous example, "%{opt1}" will be replaced by
  79.           "something-else".  Finally, if the command contains "",
  80.           those two characters will be replaced by a single % ch
  81.  
  82.  
  83.  
  84.           aracter.  (In fact, the backslash can be used to quote any
  85.           character, including itself.)
  86.  
  87.           If no "%s" appears in the command field, then instead of
  88.           placing the message body in a temporary file, metamail will
  89.           pass the body to the command on the standard input.  This is
  90.           helpful in saving /tmp file space, but can be problematic
  91.           for window-oriented applications under some window systems
  92.           such as MGR.
  93.  
  94.           Two special codes can appear in the viewing command for
  95.           objects of type multipart (any subtype).  These are "%n" and
  96.           "%F".  %n will be replaced by the number of parts within the
  97.           multipart object.  %F will be replaced by a series of
  98.           arguments, two for each part, giving first the content-type
  99.           and then the name of the temporary file where the decoded
  100.           part has been stored.  In addition, for each file created by
  101.           %F, a second file is created, with the same name followed by
  102.           "H", which contains the header information for that body
  103.           part.  This will not be needed by most multipart handlers,
  104.           but it is there if you ever need it.
  105.  
  106.           The "notes=xxx" field is an uninterpreted string that is
  107.           used to specify the name of the person who installed this
  108.           entry in the mailcap file.  (The "xxx" may be replaced by
  109.           any text string.)
  110.  
  111.           The "test=xxx" field is a command that is executed to
  112.           determine whether or not the mailcap line actually applies.
  113.           That is, if the content-type field matches the content-type
  114.           on the message, but a "test=" field is present, then the
  115.           test must succeed before the mailcap line is considered to
  116.           "match" the message being viewed.  The command may be any
  117.           UNIX command, using the same syntax and the same %-escapes
  118.           as for the viewing command, as described above.  A command
  119.           is considered to succeed if it exits with a zero exit
  120.           status, and to fail otherwise.
  121.  
  122.           The "textualnewlines" field can be used in the rather
  123.           obscure case where metamail's default rules for treating
  124.           newlines in base64-encoded data are unsatisfactory.  By
  125.           default, metamail will translate CRLF to the local newline
  126.  
  127.  
  128.  
  129.      Page 2                                          (printed 6/30/95)
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.      MMMMAAAAIIIILLLLCCCCAAAAPPPP((((4444))))       BBBBeeeellllllllccccoooorrrreeee PPPPrrrroooottttoooottttyyyyppppeeee ((((RRRReeeelllleeeeaaaasssseeee 2222))))        MMMMAAAAIIIILLLLCCCCAAAAPPPP((((4444))))
  137.  
  138.  
  139.  
  140.           character in decoded base64 output if the content-type is
  141.           "text" (any subtype), but will not do so otherwise.  A
  142.           mailcap entry with a field of "textualnewlines=1" will force
  143.           such translation for the specified content-type, while
  144.           "textualnewlines=0" will guarantee that the translation does
  145.           not take place even for textual content-types.
  146.  
  147.  
  148.           nnnneeeeeeeeddddsssstttteeeerrrrmmmmiiiinnnnaaaallll
  149.                   If this flag is given, the named interpreter needs
  150.                   to interact with the user on a terminal.  In some
  151.                   environments (e.g. a window-oriented mail reader
  152.                   under X11) this will require the creation of a new
  153.                   terminal emulation window, while in most
  154.                   environments it will not.  If the mailcap entry
  155.                   specifies "needsterminal" and metamail is not
  156.                   running on a terminal (as determined by isatty(3),
  157.                   the -x option, and the MM_NOTTTY environment
  158.                   variable) then metamail will try to run the command
  159.                   in a new terminal emulation window.  Currently,
  160.                   metamail knows how to create new windows under the
  161.                   X11, SunTools, and WM window systems.
  162.  
  163.           ccccooooppppiiiioooouuuussssoooouuuuttttppppuuuutttt
  164.                   This flag should be given whenever the interpreter
  165.                   is capable of producing more than a few lines of
  166.                   output on stdout, and does no interaction with the
  167.                   user.  If the mailcap entry specifies copiousoutput,
  168.                   and pagination has been requested via the "-p"
  169.                   command, then the output of the command being
  170.                   executed will be piped through a pagination program
  171.                   ("more" by default, but this can be overridden with
  172.                   the METAMAIL_PAGER environment variable).
  173.  
  174.      BBBBUUUUIIIILLLLTTTT----IIIINNNN CCCCOOOONNNNTTTTEEEENNNNTTTT----TTTTYYYYPPPPEEEE SSSSUUUUPPPPPPPPOOOORRRRTTTT
  175.           The metamail program has built-in support for a few key
  176.           content-types.  In particular, it supports the text type,
  177.           the multipart and multipart/alternative type, and the
  178.           message/rfc822 types.  This support is incomplete for many
  179.           subtypes -- for example, it only supports US-ASCII text in
  180.           general.  This kind of built-in support can be OVERRIDDEN by
  181.           an entry in any mailcap file on the user's search path.
  182.           Metamail also has rudimentary built-in support for types
  183.           that are totally unrecognized -- i.e. for which no mailcap
  184.           entry or built-in handler exists.  For such unrecognized
  185.           types, metamail will write a file with a "clean" copy of the
  186.           data -- i.e. a copy in which all mail headers have been
  187.           removed, and in which any 7-bit transport encoding has been
  188.           decoded.
  189.  
  190.      FFFFIIIILLLLEEEESSSS
  191.           $HOME/.mailcap:/usr/local/lib/mailcap:/usr/local/contrib/lib/metamail/mailcap
  192.  
  193.  
  194.  
  195.      Page 3                                          (printed 6/30/95)
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.      MMMMAAAAIIIILLLLCCCCAAAAPPPP((((4444))))       BBBBeeeellllllllccccoooorrrreeee PPPPrrrroooottttoooottttyyyyppppeeee ((((RRRReeeelllleeeeaaaasssseeee 2222))))        MMMMAAAAIIIILLLLCCCCAAAAPPPP((((4444))))
  203.  
  204.  
  205.  
  206.           -- default path for mailcap files.
  207.  
  208.      SSSSEEEEEEEE AAAALLLLSSSSOOOO
  209.           metamail(1)
  210.  
  211.      CCCCOOOOPPPPYYYYRRRRIIIIGGGGHHHHTTTT
  212.           Copyright (c) 1991 Bell Communications Research, Inc.
  213.           (Bellcore)
  214.  
  215.           Permission to use, copy, modify, and distribute this
  216.           material for any purpose and without fee is hereby granted,
  217.           provided that the above copyright notice and this permission
  218.           notice appear in all copies, and that the name of Bellcore
  219.           not be used in advertising or publicity pertaining to this
  220.           material without the specific, prior written permission of
  221.           an authorized representative of Bellcore.  BELLCORE MAKES NO
  222.           REPRESENTATIONS ABOUT THE ACCURACY OR SUITABILITY OF THIS
  223.           MATERIAL FOR ANY PURPOSE.  IT IS PROVIDED "AS IS", WITHOUT
  224.           ANY EXPRESS OR IMPLIED WARRANTIES.
  225.  
  226.      AAAAUUUUTTTTHHHHOOOORRRR
  227.           Nathaniel S. Borenstein
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.      Page 4                                          (printed 6/30/95)
  262.  
  263.  
  264.  
  265.